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Abstract 

This paper describes a dynamic convective 
weather avoidance concept that compensates for 
weather motion uncertainties; the integration of this 
weather avoidance concept into a prototype 4-D 
trajectory-based Airborne Separation Assurance 
System (ASAS) application; and test results from a 
batch (non-piloted) simulation of the integrated 
application with high traffic densities and a dynamic 
convective weather model. The weather model can 
simulate a number of pseudo-random hazardous 
weather patterns, such as slow- or fast-moving cells 
and opening or closing weather gaps, and also allows 
for modeling of onboard weather radar limitations in 
range and azimuth. The weather avoidance concept 
employs nested “core” and “avoid” polygons around 
convective weather cells, and the simulations assess 
the effectiveness of various avoid polygon sizes in 
the presence of different weather patterns, using 
traffic scenarios representing approximately two 
times the current traffic density in en-route airspace. 

Results from the simulation experiment show 
that the weather avoidance concept is effective over a 
wide range of weather patterns and cell speeds. 
Avoid polygons that are only 2-3 miles larger than 
their core polygons are sufficient to account for 
weather uncertainties in almost all cases, and traffic 
separation performance does not appear to degrade 
with the addition of weather polygon avoidance. 
Additional “lessons learned” from the batch 
simulation study are discussed in the paper, along 
with insights for improving the weather avoidance 
concept. 

Introduction 

Weather presents a significant source of 
uncertainty and potential delay for any air traffic 
management (ATM) system or concept, and 
convective weather (thunderstorm activity) presents 
particular challenges. Convective weather is 
challenging for flight and for ATM systems because 
it can include rapidly changing weather conditions, 


heavy rain, severe to extreme turbulence, high winds 
and gusts, hail, icing, lightning, severe downdrafts 
and microbursts, reduced ceiling and visibility, and 
instrument meteorological conditions (IMC) [1]. 
Flight planners and traffic flow management 
personnel will strategically avoid flight into areas 
with substantial coverage of current or forecast 
convective activity when possible, but there are still 
many occasions in normal operations when tactical 
avoidance of convective weather cells is required. In 
these cases flight crews will consider multiple 
information sources but will typically use onboard 
weather radar as their primary information source for 
the location of cells with the most intense 
precipitation echoes, and then employ guidelines or 
“rules of thumb” to determine safe avoidance 
distances from these echoes and their associated 
hazards. These guidelines vary with company policy 
and with flight crew judgment, but a typical example 
is the FAA guideline to avoid by at least 20 miles any 
thunderstorm identified as severe or giving an intense 
radar echo [2]. A flight crew might also modify the 
distance by which it avoids an onboard weather radar 
echo based on other factors such as pilot reports, 
visual cues, local knowledge, prior experience, and 
winds aloft. 

Dynamic convective weather avoidance is 
especially challenging for emerging en-route 4-D 
trajectory-based ATM concepts because of the 
unpredictability of weather cell “morphing” (or 
shape-changing) and translation [3] - thunderstorms 
evolve in an unpredictable manner and the future 
“velocity vector” of any given cell edge is generally 
u nk nown to any degree of precision. Furthermore, 
the weather detection and prediction capabilities of 
both airborne and ground-based weather equipment 
are limited; for example, onboard weather radar 
shows current echoes but is limited in range and 
azimuth. Trajectory-based ATM applications must 
compensate for these weather uncertainties and 
equipment limitations when building trajectories that 
avoid thunderstorms as well as traffic conflicts. For 
example, an ATM application may be given a defined 



“fly no closer than” distance for weather cells of a 
particular intensity (provided by guidelines and/or 
crew input), but if its trajectories are to reliably meet 
this constraint it must compensate for future 
unpredictable movement of the cells. 

The weather avoidance concept described in this 
paper assumes an ability to define weather “core” 
polygons laterally around detected hazardous weather 
areas (including any specified “fly no closer than” 
safety distances), and then to construct slightly-larger 
“avoid” polygons around the core polygons to 
account for weather movement uncertainty. There are 
numerous techniques in the public domain that could 
be employed to build these core polygons using radar 
imagery and safety distance parameters as input; for 
example, a previous study included both models and 
applications of weather polygons and pilot 
preferences when choosing weather avoidance routes 
[3]. The experiment described in this paper used a 
simple weather cell model and built core polygons at 
a fixed 20 nautical mile (NM) distance from the 
weather cell edges to test the weather avoidance 
concept. Weather cell morphing and translation were 
modeled by pseudo-randomly morphing the 
surrounding core polygon’s vertex positions and by 
translating the polygon at a specified velocity, 
respectively (weather cell growth/decay could be 
similarly modeled but was not examined in this 
study). Avoid polygons were built at a defined 
distance around each of the core polygons; this 
distance was an independent variable in the study of 
the concept’s effectiveness. In all cases the polygon 
dimensions were uniform at all altitudes - that is, 
they were “extruded” vertically through all altitudes 
in the airspace of interest - but the concept could be 
generalized to weather polygons that vary in 
dimension and extent with altitude. 

The weather avoidance concept has been 
integrated into NASA Langley Research Center’s 
Autonomous Operations Planner (AOP), which is a 
prototype airborne separation assurance system 
(ASAS) ATM application [4,5], but the concept 
could also be applied to a ground-based ATM 
application [6,7]. The AOP is designed to detect 
traffic conflicts using ADS-B state and intent 
information, and weather conflicts using the 
avoidance concept and input from an onboard 
weather radar model, and then to provide crews with 
conflict-free trajectories that simultaneously avoid 


both traffic and weather conflicts. The resolution 
trajectories generated by AOP satisfy traffic flow 
management constraints such as a required time of 
arrival (RTA) at a metering fix. 

The next section of the paper describes the 
weather avoidance concept in more detail, followed 
by a section describing its integration into an ASAS 
application (AOP). Next, our weather model for 
simulating weather cell patterns, onboard weather 
radar and polygon generation is described, followed 
by a section that describes a batch (non-piloted) 
simulation experiment we conducted that used the 
weather model to test the integrated weather 
avoidance and traffic separation (ASAS) application. 
Subsequent sections present the results of the 
experiment, discuss the results with respect to 
concept effectiveness and possibilities for 
improvement, and provide some concluding remarks. 

The Weather Avoidance Concept 

As stated in the introduction, the weather 
avoidance concept assumes the availability of an 
external “polygon generator” application that is 
capable of constructing core polygons around 
detected convective weather cells and any specified 
minimum safety distance that is to be maintained 
from them. It is also assumed that the polygon 
generator would provide a new, updated set of core 
polygons at regular intervals as new weather cell data 
are detected. These core polygons would then 
become “hard constraints” for an ATM trajectory- 
generation algorithm, in the same way that restricted 
airspace or the minimum separation distance around 
other aircraft would also be hard constraints; that is, 
conflict-free 4-D trajectories must avoid all hard 
constraints. However, the weather core polygons 
differ from the other hard constraints in that their 
positions, velocities, shapes, and even the total 
number of them change with their updates over time 
in unpredictable ways. This unpredictability tends to 
make the computation of weather-conflict-free 4-D 
trajectories an intractable problem - there is no way 
to prevent an updated core polygon edge from 
moiphing or moving over the aircraft’s position on a 
formerly conflict-free trajectory that was skirting the 
polygon’s old position. 

One approach to solving this problem is to 
construct a slightly-larger avoid polygon of size “D” 
around each core polygon (illustrated notionally in 



Figure 1) and to define these avoid polygons as “soft 
constraints.” If possible, soft constraints will be 
avoided along with hard constraints when (new) 
weather data are received and trajectories are 
(re)computed, but if no such solutions are available 
then a trajectory may be offered that penetrates a soft 
constraint (with minimal-penetration solutions given 
preference by the algorithm over progressively 
deeper penetrations). More significantly, if a 
formerly conflict-free trajectory later becomes 
conflicted with an avoid polygon that has moved over 
the aircraft’s current position, the current trajectory is 
still acceptable (all hard constraints are still avoided), 
but the algorithm will begin seeking a new trajectory 
that will exit the avoid polygon and is subsequently 
free of conflicts with all hard and soft constraints 
(Figure 2). In essence, the avoid polygons buy the 
algorithm time and give it early warning that one or 
more core polygon edges are moving toward its 
trajectory. 


Avoid Polygon 
Size "D" 




Many variables can be used and assigned 
different weights by an algorithm when computing 
trajectories that must pass through avoid polygons; 


such trajectories may be required either to clear other 
hard constraints or to exit an avoid polygon that has 
moved over the aircraft’s position. Some examples 
of these variables include distance from core 
polygons, time or distance spent within avoid 
polygons, time/distance spent within overlapping 
avoid polygons, and aggressiveness of exit maneuver 
relative to current heading. To date we have selected 
variables and weightings that maximize distances 
from core polygons, and minimize time flown in 
avoid polygons, when computing trajectories that 
pass through or exit avoid polygons. Figure 2 (not 
drawn to scale) shows the effects of using these 
variables when computing an exit trajectory from an 
avoid polygon: the red trajectory is unacceptable 
because it penetrates the core polygon within the 
trajectory’s look-ahead time (represented by the 
arrow lengths), and the green trajectory labeled “L3” 
is optimal because it maximizes distance from the 
core polygon and exits the avoid polygon in 
minimum time. Green trajectories L2 and LI are 
acceptable but progressively less desirable (i.e., they 
are lower- weighted as solutions) in this example with 
only a single core and avoid polygon; currently there 
is no penalty for maneuver aggressiveness when 
exiting an avoid polygon, other than a maximum 
heading change of 60 degrees. Figure 3 introduces a 
second, overlapping core and avoid polygon to the 
example shown in Figure 2. In this case trajectory L2 
is optimal in meeting all of the weighted variables; it 
“splits the difference” between the two core polygons 
and minimizes total time in avoid polygons (time that 
would be spent in overlapping avoid polygon areas is 
doubly penalized). 

“Better" "Best" 



Clearly, large avoid polygons (i.e., large values 
of “D” in Figure 1) are likely to minimize core 
polygon penetrations but at the same time block large 
areas of airspace and introduce larger system 


disruptions. Small avoid polygons are likely to 
improve trajectory and airspace efficiency but be less 
effective in preventing core polygon intrusions. The 
optimal avoid polygon size range would likely be 
affected by the maximum cell edge speeds and the 
types of weather patterns, and should also be affected 


by the update frequency for new core polygons (i.e., 
more frequent updates should allow for smaller avoid 
polygons). The avoid polygon size and weather 
pattern type/speed are the independent variables in 
the experiment described later in the paper. 
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Figure 4, On-board Weather Avoidance Architecture 


Integrating Weather Avoidance into an 
ASAS Application 

Figure 4 depicts a notional architecture showing 
the main components of an ASAS application (i.e., 
AOP) integrated with the weather avoidance concept 
and using onboard weather radar as its hazardous 
weather information source. Onboard weather radar 
was selected for this architecture because: 1) it is 
currently available and required on all transport 
category aircraft in air transportation service, 2) it is 
the primary weather information source for tactical 
avoidance of convective weather when in IMC, 3) it 
provides the most immediate and frequently-updated 
image of hazardous weather relevant to the aircraft’s 
flight path, and 4) its status as an onboard weather 
information source is more consistent with the 
autonomous nature of an ASAS application than 
critical reliance on reception of ground-based 
weather information sources. That is, while the 
future availability of flight information services (FIS) 
weather data may augment and improve strategic, 
and possibly tactical, weather avoidance trajectory 
generation by an ASAS application, it should not be 
relied upon as the primary weather information 
source. 


As depicted in Figure 4, the onboard weather 
radar would provide a near-real-time weather image 
to a polygon generator application; this weather 
image would necessarily be limited or “cropped” by 
the radar’s azimuth and range limitations. The 
polygon generator would compute a set of core 
polygons around weather in this image that exceeds a 
specified intensity level, using either default safety 
distance settings and/or input from the flight crew, 
and also generate a set of avoid polygons surrounding 
the core polygons. This set of core and avoid 
polygons would then be provided to the weather 
avoidance logic embedded in the ASAS application, 
to be used as hard and soft constraints when 
computing conflict-free trajectories. At regular 
intervals (30 seconds in the current simulation of this 
architecture), the polygon generator would provide an 
updated set of core and avoid polygons to the weather 
logic, at which time the logic would discard the old 
set and replace it with the new, and reassess the 
current trajectory for conflicts. The integrated 
weather avoidance/ASAS application would present 
the weather imagery and polygons, trajectories and 
weather/traffic conflicts (if any) to the flight crew on 
the appropriate displays, which should facilitate crew 
decisions and possible input to the polygon generator 
and/or weather avoidance logic. 



In order to test the effectiveness of the integrated 
weather/ASAS application in the batch simulation 
described later in the paper, the actual weather, 
onboard weather radar and polygon generator was 
represented with a simple parametric convective 
weather model, as shown by the dashed outline in 
Figure 4 and as described in the next section. Also, 
the current instantiation of the architecture shows 
only the weather core and avoid polygons (and not 
the actual weather imagery) on each simulated 
aircraft’s navigation display, since display of the 
actual weather imagery is not needed for batch 
simulations with automated pilot models in place of 
human pilots. 

The Weather Model 

The weather model is designed to simulate a 
number of pseudo-random convective weather 
patterns, such as slow- or fast-moving cells and 
opening or closing weather gaps, and to generate the 
core and avoid weather polygons that would result 
from an aircraft’s onboard radar encountering this 
simulated weather from a given position. It is highly 
parameterized, enables modeling of onboard weather 
radar limitations in range and azimuth, and 
dynamically updates the polygons as the weather 
moves and the onboard weather radar view changes. 

The weather model accepts as input a cell 
pattern and safety distance specified by the 
researcher, and builds simple core polygons around 
these cells at that distance. Each cell is assumed to 
have the same cross-section at all altitudes of interest, 
so the resulting polygons are “extruded” vertically 
throughout all altitudes in the test area. For the 
experiment described in this paper, all patterns were 
built up from one or two 10 NM- diameter circular 
weather cells with uniform 20 NM safety distances 
around them, which resulted in 50 NM 
circumscribed-diameter core polygons (hexagons) 
around each of these cells. 

Each of the weather cells in a pattern are 
assumed to randomly morph (that is, change shape by 
dilating or contracting along any given edge), and 
each cell may also be assigned a translation velocity. 
Cell translation is simulated by updating each of its 
core polygon vertex positions at the specified 
translation rate. Cell moiphing is simulated by 
randomly repositioning the core polygon vertices 
around their nominal locations at user specified 


update rates and distances. For the experiment 
described here, each vertex position was randomly 
updated within ± 3 NM of its nominal position on a 
5 -minute schedule, with intermediate vertex positions 
interpolated in time. This results in polygon vertices 
and edges that randomly morph at rates varying from 
0 to 70 knots (kts), superimposed on any overall cell 
translation velocity. 

The weather model provides these dynamically- 
updating “scenario-wide” core polygons to all aircraft 
in a simulation scenario at a regular update rate (30 
seconds for the experiment described here), but must 
also model for each aircraft the unique core and avoid 
polygons that it would generate based on its radar 
view of the weather cells associated with these 
scenario-wide polygons. The weather model does 
this for each aircraft by employing a simple cropping 
algorithm to simulate the radar’s limited range and 
azimuth, as shown in Figure 5. In this figure the 
scenario-wide core polygon is shown in tan, the 
radar-cropped core polygon detected by this aircraft 
is orange, and the avoid polygon it would build 
around this cropped core polygon is outlined in 
green. For this experiment the radar cropping range 
was set at 80 NM (equivalent to detecting the actual 
weather cell at 100 NM, due to the 20 NM safety 
distance) and the azimuth was cropped at ± 60 
degrees. 



Experiment Description 

An exploratory batch simulation study was 
conducted to investigate the effectiveness of the 
integrated weather/ASAS application in the presence 
of various weather patterns and with various avoid 
polygon sizes, using traffic scenarios that represent 


approximately twice the current traffic density in en- 
route airspace. Five different weather patterns were 
scripted to model a range of complexity levels and 
are illustrated in Figure 6. The “Stationary Cell” 
pattern consists of a single weather polygon that is 
stationary at the test region center, while the “30- kn ot 
Cell” and “60-knot Cell” patterns consist of a 
polygon translating across the test region at 30 and 60 
kts, respectively. The “Opening Gap” pattern consists 
of two initially overlapping polygons, one stationary 
and the other translating away at 30 kts to open an 
airspace gap in between them. The “Closing Gap” 
pattern has one stationary polygon and another 
polygon translating toward it that closes an airspace 
gap between them, the reverse of the previous case. 

Simulation Platform 

The simulation runs described herein were 
conducted in the Air Traffic Operations Laboratory 
(ATOL) at NASA Langley Research Center utilizing 
a distributed simulation platform known as the 
Airspace & Traffic Operations Simulation (ATOS) 
[4,5]. The ATOS batch platform is comprised of 
hundreds of real-time aircraft simulators, each 
equipped with a version of AOP in which the new 
weather avoidance functionality is implemented. 
Conceptually, the ATOS batch simulation platform is 
a system composed of multiple distributed 
autonomous software agents modeling ASAS- 
equipped aircraft flown by a pilot model application. 
In the current study, the pilot model was configured 
to react to all traffic and weather conflict alerts by 
requesting a resolution trajectory from the AOP and 
executing it. 



Figure 6. Weather Patterns 


Experiment Scenarios and Assumptions 

The experiment scenarios consisted of a notional 
en route airspace sector modeled as a circular area 
with a diameter of 1 60 NM. Aircraft were generated 
at random points along a circle 80 NM 

(approximately 1 0 flying minutes) away from the test 
region boundary, with initially straight trajectories 
traversing the test region in sets of converging flows 
towards multiple metering fixes placed 

approximately 300 NM outside the test region. More 
information on the random scenario simulation 
platform can be found in [8]. Each aircraft was 
assigned an RTA constraint (set to its ETA at 


generation time) at its respective metering fix. All 
aircraft in the simulation were generated at cardinal 
altitudes uniformly distributed between Flight Level 
(FL) 290 and FL 390. ADS-B air-to-air reception was 
modeled to be perfect (no degradation or errors due 
to interference) out to a range of 120 NM, with no 
reception beyond this range. A wind field was 
present, with uniform winds of 40-50 kts at each 
flight level and moderate changes in speed and 
direction with altitude, but no wind forecast errors 
were introduced (i.e, all aircraft had ideal knowledge 
of the wind field). Weather patterns were extruded 
vertically, as previously stated, which enforced 
lateral resolution maneuvers around weather 
conflicts. Traffic conflicts could be resolved either 
laterally or vertically. 

The traffic density in all scenarios was 
maintained at a level representative of twice the 
current traffic density levels for high altitude, en- 
route airspace sectors in the National Airspace 
System. Details on the traffic density estimation are 
contained in [9]. This density equated to 60-70 
aircraft concurrently in the 160 NM circular test area 
throughout each test run of 160 minutes. 

Experiment Design 

A 5x6 factorial experiment design was used to 
collect data on the five weather patterns and six avoid 
polygon sizes, for a total of 30 experiment scenarios 
as shown in Table 1. The six levels of avoid polygon 
size represent a range from 1 NM to 9 NM. 


Table 1: Experiment Design Matrix 


Weather Pattern 

Avoid Polygon 
Size (NM) 

Stationary Cell 

1,2, 3, 5, 7,9 

30-Knot Cell 

1,2, 3, 5, 7,9 

60-Knot Cell 

1,2, 3, 5, 7,9 

Opening Gap 

1,2, 3, 5, 7,9 

Closing Gap 

1,2, 3, 5, 7,9 


Three sets of baseline scenarios were also 
conducted for each of the five weather patterns. 
Baseline 1 corresponded to scenarios with both traffic 
and weather conflict resolutions disabled, and thus no 
attempts were made to resolve any conflicts. Baseline 

2 scenarios incoiporated traffic conflict resolutions 
but no resolutions around weather conflicts. Baseline 

3 scenarios included weather avoidance maneuvers 


(with a 5 NM avoid polygon size) but no traffic 
conflict resolutions. 

Experiment Results 

Two replicates of each of the 30 experiment 
scenarios and the 15 baseline scenarios described 
above were conducted. The 90 test runs resulted in a 
total of approximately 20,000 simulated flight hours, 
or approximately 450 flight hours for each 
experiment or baseline scenario. 

Dependent Measures 

Several dependent measures were examined as 
applicable for each experiment and baseline scenario, 
including the number of detected conflicts with 
traffic and with weather polygons, the number of 
aircraft loss of separation (LOS) and weather core 
area (polygon) penetration (CAP) events, and the 
excess lateral path length that ensued due to traffic 
and weather avoidance. Results for each of these 
dependent measures are described in subsequent 
subsections. 

Results for conflict, LOS, and CAP events have 
been normalized to the number of respective events 
per thousand flight hours. While this normalization 
should help convey the operational significance of 
the numbers, it should also be noted that these 
normalized results are extrapolations since only about 
450 flight hours were simulated for each experiment 
scenario. For example, a single event (e.g., a CAP) 
occurring among all the aircraft flying in a particular 
experiment scenario will translate into a reported 
(i.e., extrapolated) result of two events per thousand 
hours. 

In the experiment (i.e., non-baseline) scenarios 
where both weather and traffic conflict resolution 
algorithms were active, LOS and CAP events were 
both relatively rare and of forensic interest, so all 
such events were manually replayed and analyzed by 
the researchers. This analysis revealed that slightly 
over half of the LOS and/or CAP events in the raw 
data were due to simulation errors rather than to 
failures of the conflict resolution concepts or 
implementation, and these “simulation error” LOS 
and CAP events were excluded from the reported 
results. The simulation errors were typically rare race 
conditions and comer-case interactions between the 
Flight Control Computer (FCC), Flight Management 
System (FMS) and Pilot Model (PM) code modules. 




PM errors would cause the PM logic to stop 
responding correctly to the AOP’s conflict-resolution 
alerts and commands, and were detected by the 
resulting CAP or LOS events. The FCC/FMS errors 
would cause departures from the commanded (and 
LO S/CAP -protected) flight path and in some cases 
would result in extensive circling of the aircraft in an 
attempt to recapture the commanded flight path. 
Manual examination of several hundred flight tracks 
(out of approximately 50,000 total) indicated that this 
circling simulation error occurred in only a few 
percent of the sampled flights, but when it did occur 
it significantly added to the total path length of the 
flight. 

It should be noted that while these simulation 
errors appear to be relatively rare and were manually 
excluded from the reported LOS and CAP results, as 
of this writing there is no practical, automated 
mechanism to detect and exclude all other such errors 
from the detected conflict count and excess path 
length dependent measures. Since the simulation 
errors appear relatively few compared to the large 
number of detected conflicts, they are unlikely to 
dominate the reported results of this dependent 
measure. Likewise, the errors should not greatly 
affect the median excess path length dependent 
measure because of the much larger number of error- 
free cases also included in this measure. However, 
the errors will affect the maximum excess path length 
and, to some extent, the mean excess path length 
measures. The effects of the likely presence of 
simulation errors in the excess path length dependent 
measures are described in the respective Discussion 
subsection. 

Number of Detected Conflicts 

The number of conflicts was computed as the 
total number of conflict detections for which the 
predicted LOS, CAP or Avoid Area Penetration 
(AAP) occurred partially or completely inside the test 
region. Figures 7 and 8 present the number of traffic 
and weather conflict detections per 1,000 flight 
hours, respectively. It can be seen that both traffic 
and weather conflict counts are higher for larger 
avoid polygon sizes and more complex weather 
patterns. The number of weather conflicts in the 
scenarios with two weather cells (Opening Gap and 
Closing Gap) is approximately two times that in the 
scenarios with only one weather cell (Stationary, 30- 
knot Cell, and 60-knot Cell), as expected. 



Avoid Polygon Size (NM) 


Figure 7. Traffic Conflicts/1000 Hours 



Avoid Polygon Size (NM) 

Figure 8. Weather Conflicts/1000 Hours 

Statistical analysis of the dataset was performed 
using an Analysis of Variance (ANOVA). Significant 
main effects were found for avoid polygon size (p = 
0.0071) and weather pattern (p < 0.0001) for the 
number of traffic conflict detections. However, the 
interaction between these two factors was not 
significant (p = 0.0662). Note that a p-value < 0.05 
indicates a statistically significant effect. Avoid 
polygon size (p < 0.0001), weather pattern (p < 
0.0001) and the interaction {p < 0.0001) were all 
found to have a significant effect on the number of 
weather conflict detections. 

Losses of Separation 

The number of losses of separation per 1,000 
flight hours is shown in Table 2 for each scenario. 
The criteria for LOS were a closest point of approach 
(CPA) within 5 NM laterally and 800 ft vertically. 
LOS events occurred in only two of the 30 
experiment scenarios, and both weather pattern and 
avoid polygon size seem to have little impact on this 
metric. The LOS in the run with the 30-knot cell and 
an avoid polygon size of 7 NM resulted in a CPA of 
2.344 NM. In the run with the opening gap weather 


pattern and a 5 NM avoid polygon, the LOS had a 
CPA of 4.841 NM. By comparison, the LOS 
numbers are quite high (hundreds) for both the 
Baseline 1 and Baseline 3 scenarios where the traffic 


resolution logic was disabled. There were no LOS 
events in the Baseline 2 scenarios where traffic 
resolution was enabled but weather resolution was 
disabled. 


Table 2. LOS per 1000 Flight Hours 


Weather Pattern 

Avoid Polygon Size (NM) 

Baseline Scenarios 

9 

7 

5 

3 

2 

1 

Basel 

Base2 

Base3 

Stationary Cell 

0 

0 

0 

0 

0 

0 

528 

0 

614 

30-Knot Cell 

0 

2 

0 

0 

0 

0 

545 

0 

569 

60-Knot Cell 

0 

0 

0 

0 

0 

0 

527 

0 

660 

Opening Gap 

0 

0 

2 

0 

0 

0 

553 

0 

764 

Closing Gap 

0 

0 

0 

0 

0 

0 

600 

0 

698 


Table 3. CAP per 1000 Flight Hours 


Weather Pattern 

Avoid Polygon Size (NM) 

Baseline Scenarios 

9 

7 

5 

3 

2 

1 

Basel 

Base2 

Base3 

Stationary Cell 

0 

0 

0 

0 

4 

2 

693 

646 

0 

30-Knot Cell 

0 

0 

0 

0 

0 

2 

759 

708 

0 

60-Knot Cell 

0 

0 

0 

0 

0 

16 

709 

646 

0 

Opening Gap 

0 

0 

5 

2 

2 

2 

1326 

1343 

0 

Closing Gap 

2 

7 

2 

9 

5 

14 

1373 

1347 

7 


Weather Penetrations 

Table 3 presents the number of CAP events per 
1,000 flight hours for each scenario. The highest 
number of CAP events in the experiment scenarios 
occurred with the 60-knot Cell and Closing Gap 
weather patterns and the smallest avoid polygon size 
of 1 NM, but even in these two cases the CAP counts 
are less than 20 per 1,000 flight hours. By 
comparison, the CAP numbers are quite high 
(hundreds to thousands) for both the Baseline 1 and 
Baseline 2 scenarios where the weather resolution 
logic was disabled. The number of CAP events in the 
baseline scenarios with two weather cells (Opening 
Gap and Closing Gap) is approximately two times 
that in the baseline scenarios with only one weather 
cell (Stationary, 30-knot Cell, and 60-knot Cell), as 
expected. 

Figure 9 shows the distance the aircraft 
penetrated the core polygon for each CAP that 
occurred during the scenario runs. Of the 33 
penetrations, 24 were less than 1.5 NM into the core. 
All of the remaining larger penetrations, including 
the three largest penetrations of between 9 and 


10 NM, occurred with the closing gap weather 
pattern. 



Figure 9. CAP Depth Distribution 
Excess Path Length 

Descriptive statistics for excess lateral flight 
path length by weather pattern and avoid polygon 
size are shown in Tables 4 and 5, respectively. The 
Opening Gap and Closing Gap weather patterns 
result in a mean lateral flight path length almost twice 
as large as with the Stationary Cell, 30-knot Cell and 
60-knot Cell patterns. Additionally, the mean excess 






path length increases slightly for all weather patterns 
as the avoid polygon size increases. 


Table 4. Excess Path Length (NM) versus Weather Pattern 


Weather 

Pattern 

N 

Mean 

Std. 

Dev. 

Min. 

Median 

Max. 

Stationary Cell 

6461 

4.3 

8.1 

0 

0.7 

78 

30-Knot Cell 

6425 

4.9 

9.4 

0 

0.8 

116 

60-Knot Cell 

6476 

5.4 

10.8 

0 

0.8 

130 

Opening Gap 

6497 

8.9 

14.1 

0 

3.2 

358 

Closing Gap 

6438 

9.1 

14.3 

0 

2.9 

114 


Table 5. Excess Path Length (NM) versus Avoid Polygon Size 


Avoid Polygon 
Size (NM) 

N 

Mean 

Std. 

Dev. 

Min. 

Median 

Max. 

1 

5333 

5.4 

10.2 

0 

0.9 

114 

2 

5348 

5.5 

10.2 

0 

0.9 

108 

3 

5411 

6.1 

11.3 

0 

0.9 

116 

5 

5392 

6.7 

12.7 

0 

1.1 

358 

7 

5416 

7.3 

12.3 

0 

1.3 

130 

9 

5397 

8.2 

13.4 

0 

2.0 

151 


Data were averaged over all aircraft in a run, and 
least squares regression was used to fit the data. The 
model for excess lateral flight path length is given 
below. It has an R 2 of 96%, indicating that it is a 
good approximation of the relationship between 
excess flight path (EP), weather pattern, and avoid 
polygon size (D). 


Stationary Cell: 
30-knot Cell: 
60-knot Cell: 
Opening Gap: 
Closing Gap: 


EP = 3.34 + 0.22*D 
EP = 3.93 + 0.22*D 
EP = 4.53 + 0.19*0 
EP = 6.13 + 0.61*D 
EP = 6.71 + 0.54*D 


Avoid polygon size (p < 0.0001), weather 
pattern (p < 0.0001), and the interaction between 
these two factors (p < 0.0001) were found to have a 
statistically significant effect on the mean excess 
lateral flight path length. 


Discussion of Results 

Number of Detected Conflicts 

Figures 7 and 8 show, respectively, that on 
average an aircraft flying in these experiment 
scenarios might expect to encounter between one and 
two traffic conflicts per hour, and between two and 
seven weather conflicts per hour. Moreover, Figure 8 
shows that the most weather conflicts occur when 
two weather cells are present and the avoid polygon 
sizes are large. The increase in conflicts between the 
one-cell and two-cell scenarios is likely due to twice 
as much usable airspace being consumed by two 
weather polygons as by one, and for the same reason 
the conflict count also increases as the avoid polygon 
size is increased. That is, the use of large avoid 
polygons exacts a penalty by increasing the number 
and rate of weather conflicts that must be resolved by 
the automation and flight crew. 

Operationally, resolving between two and seven 
weather conflicts per hour should not pose an undue 
burden on flight crews, but these average numbers 
tell only part of the story. By detailed inspection of 





the simulation data it is clear that many aircraft 
negotiate the weather they encounter with the use of 
only a single conflict resolution, or in some cases 
with no resolution at all if weather and traffic are not 
encountered on their original flight plan route. Other 
aircraft are not so lucky, and some of the outlier cases 
exceed 30 conflicts per hour, which would almost 
certainly pose an unacceptable workload to a busy 
flight crew negotiating through weather cells. 
Inspection and replay of these outlier flights indicate 
at least two improvements that could be made to the 
weather avoidance concept; these improvements are 
described in the next two paragraphs. 

The first improvement to the concept would be 
to include a “resolution polygon” around each 
core/avoid polygon set that is slightly larger (e.g., 1- 
2 NM) than the avoid polygon. Then when a conflict 
is detected with a weather core and/or avoid polygon, 
the resolution logic would attempt to compute a 
conflict-free trajectory that also clears the resolution 
polygon. As the core/avoid polygon edges 
subsequently move with time, this new trajectory 
should remain conflict-free longer than an optimized 
trajectory which is computed right up against the 
edge of an avoid polygon, and which becomes almost 
immediately conflicted again if/when the avoid 
polygon moves over it. This phenomenon of 
repeated new weather conflicts was observed in many 
of the high-conflict outlier cases, especially when 
flying resolution trajectories that skirt the downwind 
side of moving cells (recall that the weather 
avoidance algorithm assumes no reliable knowledge 
of cell motion), but also when skirting unpredictably 
moiphing polygon boundaries. 

The second concept improvement would be to 
add a “short-term weather memory” capability to the 
weather polygon generation software. The concept 
as it is currently instantiated and modeled assumes 
that the polygon generation software would use the 
onboard weather radar imagery as source data, would 
generate a current set of weather core and avoid 
polygons from this imagery at frequent intervals, and 
at each interval would replace the old set of polygons 
with the new for use by the weather polygon conflict 
resolution logic. A problem with this concept is that 
cells to the left and right of the aircraft are cropped 
and “disappear” at the azimuth limits of the radar as 
the aircraft moves ahead, and their respective 
polygons are cropped as well. While a crewmember 


would remember that a hazardous cell is still abeam 
the aircraft, even though no longer shown on the 
radar, the conflict resolution logic has no such short- 
term memory and will often propose new trajectories 
through what it assumes is now weather-free airspace 
to the left or right of the aircraft. This problem is 
particularly troublesome when emerging from a close 
gap between two core polygons but still within both 
associated avoid polygons - as either the right or left 
cell disappears from the radar view, the polygon 
generator eliminates its respective core and avoid 
polygons, and the conflict resolution logic then 
commands a somewhat aggressive turn away from 
the remaining cell to fly clear of its avoid polygon. 
Needless to say, shortly after commencing this turn 
the radar “rediscovers” the cell in the direction of the 
turn, and “forgets” the other cell as it leaves the radar 
view, resulting in an unnecessary weather conflict 
and a commanded turn in the opposite direction. 
This behavior was nicknamed the “windshield wiper 
instability” because it would often lead to multiple 
weather conflicts and left-right turns until well clear 
of both cells. Such behavior and its excessive 
weather conflicts could be eliminated with a short- 
term weather memory built into the polygon 
generator, where weather polygon segments that 
move out of radar azimuth limits are retained for one 
or two minutes and supplied to the resolution logic as 
part of the current polygon set. 

LOS and CAP Events 

As stated in the Results section, only two LOS 
events occurred in all of the experiment and baseline 
scenarios where traffic conflict resolution logic was 
enabled. In both of these cases the logic failed to 
detect and present the traffic conflict, for reasons that 
are still under investigation, but neither the weather 
scenarios, avoid polygon size, nor weather avoidance 
logic appear to be a factor in these two LOS events. 
More generally, the addition of weather conflict 
resolution logic does not appear to affect or 
compromise the traffic conflict resolution capabilities 
in the software; LOS rates remain low and do not 
appear to degrade with the addition of weather 
polygons and conflict resolutions. 

Weather CAP rates are generally quite low: the 
overall CAP rate for all scenarios where the weather 
conflict avoidance logic is enabled is approximately 
0.6% of the CAP rate for the Baseline 1 and 2 
scenarios where the weather conflict resolution logic 



is disabled. In fact, no CAP events occurred in a 
majority (20 of 35) of the scenarios where the 
weather resolution logic was enabled. Based on both 
the data and playback observations it appears that 
avoid polygon sizes as small as 2 or 3 NM are 
effective at preventing CAP events, but an avoid 
polygon size of 1 NM is too small to prevent some 
CAP events for the weather patterns evaluated in this 
experiment, especially for fast-moving cells or 
closing gaps. 

The Closing Gap weather pattern, and to a lesser 
extent the Opening Gap pattern, generally had more 
CAP events than the other patterns even with larger 
avoid polygons. The majority of these CAP events 
involved only slight “grazing” penetrations into the 
core polygon, but some resulted in significant 
penetrations of as much as 1 0 NM. These and other 
CAP events were examined and analyzed for cause, 
as described in the following paragraphs. 

One reason that more CAP events occur for the 
two-polygon patterns is because the maneuvers 
necessary to deviate around these weather areas are 
sometimes larger than the limits currently built into 
the conflict resolution logic. The current limits for 
turn angle, lateral offset distance, etc. are designed 
for traffic conflict resolutions and are relatively 
modest compared to what is sometimes required to 
tactically deviate around weather once it is detected. 
In cases where a weather conflict could not be 
resolved because of these limits, the logic would 
present the conflict but provide no resolution, and the 
Pilot Model would take no action and continue on the 
aircraft’s original FMS flight plan, sometimes 
resulting in significant penetrations into the core 
polygon. It should be possible to eliminate such CAP 
cases by relaxing the resolution angle and offset 
limits for weather conflicts. 

A related but more serious reason for occasional 
deep CAP events arises when the gap between 
polygons is open but narrow and several co-altitude 
aircraft are concurrently attempting to pass through 
it. The current resolution logic will seek either a 
lateral or a vertical resolution but not a composite 
lateral and vertical resolution, and several CAP 
events were observed where the logic could not find a 
resolution through the gap that was free of both 
traffic and weather conflicts. In these cases the 
conflicts were presented but a resolution was not 
provided, resulting in (sometimes significant) CAP 


events. Some of these CAP events could likely be 
prevented by adding composite lateral/vertical 
resolution patterns to the logic, so that aircraft could 
avoid the weather laterally and each other vertically. 
However, the more general solution to this airborne 
separation problem likely involves external means of 
either reducing traffic/weather complexity so that a 
conflict-free resolution can always be found, or 
devising algorithms and/or procedures that provide 
alternatives when a resolution is not forthcoming. 
Such a general solution is beyond the scope of this 
study. 

The majority of CAP events were slight 
penetrations into the core polygon and occurred with 
a 1 NM avoid polygon size and either the 60-knot 
Cell or Closing Gap weather patterns. In the case of 
the 60-knot Cell weather pattern, a CAP would 
typically occur while an aircraft was closely 
deviating around the downwind side of the cell and 
simply got “run over” by the core polygon. With the 
Closing Gap pattern the aircraft was often “pinched 
by the gap” - that is, the gap closed after the aircraft 
was committed to passing through it, resulting in 
grazing penetrations into one, or sometimes both, of 
the core polygons on either side of the closing gap. 
Avoid polygon sizes greater than 1 NM eliminated 
these grazing CAP penetrations for both the 60-knot 
Cell and Closing Gap patterns. 

A few CAP events were due to software failures 
in the weather conflict resolution logic, including 
failure to detect the weather conflict, and turning 
toward rather than away from a core polygon in the 
absence of other conflict constraints. The reasons for 
these software failures are currently under 
investigation. 

Excess Path Length 

The median and mean values of excess path 
length are relatively low (less than 4 NM and 1 0 NM, 
respectively) from an operational perspective for all 
weather patterns and avoid polygon sizes, and are 
smaller for the simpler weather patterns and smaller 
avoid polygon sizes, as expected. Such small average 
excess path lengths should generally not pose a 
problem for meeting a downstream RTA, since the 
aircraft could likely compensate for the extra path 
length with a slight speed increase. However, the 
maximum excess path length values are high for all 
experiment scenarios (values between 78 and 



358 NM), indicating that some flights are either 
receiving inefficient routing and/or are “victims” of 
the simulation errors described in the Results section 
for path length. We have observed anecdotal 
evidence of both behaviors. Clearly, such large 
excess path lengths are unacceptable from an 
operational perspective, even for a few unlucky 
aircraft, and these outlier cases are currently under 
investigation to resolve simulation errors and uncover 
any inefficient routing issues. 

Least squares regression analysis of the excess 
path length data show longer paths for more complex 
weather patterns, as expected, but also show a 
significantly higher penalty (approximately 3 times 
as great) for larger avoid polygons with the two-cell 
patterns versus the single-cell patterns. Some of this 
penalty might be explained because increasing the 
size of two avoid polygons rather than just one 
eliminates usable airspace at twice the rate, but some 
penalty is also likely due to weather “gaps” being 
eliminated more aggressively, causing more lengthy 
deviations around both cells. Either way, it 
highlights the importance of minimizing avoid 
polygon sizes to maximize efficiency, especially for 
more complex weather patterns. 

Conclusions 

Results from the batch simulation tests of the 
integrated weather avoidance and traffic separation 
application described in this paper show that the 
weather avoidance concept is effective over a wide 
range of weather patterns and cell speeds. Avoid 
polygons that are only 2-3 NM larger than their core 
polygons are sufficient to account for weather 
uncertainties in almost all cases, and traffic 
separation performance does not appear to degrade 
with the addition of weather polygon avoidance. 

High conflict counts occurred in some cases due 
to lack of resolution buffers and/or “short-term 
weather memory,” both of which are discussed in the 
paper and suggested as improvements to the weather 
avoidance concept. Weather CAP events occurred in 
a few cases because no conflict-free resolution could 
be found, due either to maneuver limits in the 
resolution algorithms that are insufficient for some 
weather deviations, or to excessive traffic complexity 
in narrow weather gaps. Excess path length due to 
traffic and weather avoidance was small in most 
cases, but in a few cases was excessive; some of 


these excessive path length cases were due to 
simulation errors and some were because the 
algorithm returned inefficient trajectories. The 
number of, and causes for, the inefficient trajectories 
is under investigation. 

Future work in this area would include 
implementing the resolution buffer and weather 
memory improvements to the weather avoidance 
concept, and developing and evaluating optimal 
weather presentations and interfaces for the flight 
crew. It would also be fruitful to test the integrated 
weather avoidance and ASAS application with actual 
recorded weather data and polygon generation 
software, and to compare the flight tracks and 
performance from those tests with actual traffic that 
was flown at the time and in the regions with the 
recorded weather. 

References 

[1] Chamberlain, James and Kara Latorella, Ph.D., 
2001, Convective Weather Detection by General 
Aviation Pilots with Conventional and Data-Linked 
Graphical Weather Information Sources, 20 th Digital 
Avionics System Conference, Daytona Beach, FL. 

[2] Federal Aviation Administration, 2010, 
Aeronautical Information Manual, 2011 Edition, 
Newcastle, WA, Aviation Supplies and Academics, 
Inc., Chapter 7, Section 7-1-29 Thunderstorm Flying. 

[3] Rubnich, Mikhail and Rich DeLaura, 2010, An 
Algorithm to Identify Robust Convective Weather 
Avoidance Polygons in En Route Airspace, 10 th 
A1AA Conference on Aviation Technology, 
Integration and Operations, Fort Worth, Texas. 

[4] Karr, D., D. Roscoe and R. Vivona, August 2004, 
An integrated flight-deck decision-support tool in an 
autonomous flight simulation, A1AA Modeling and 
Simulation Technologies Conference and Exhibit, 
AIAA-2004-526 1 . 

[5] Karr, D., D. Roscoe and R. Vivona, August 2006, 
Conflict detection using variable 4D uncertainty 
bounds to control missed alerts, AIAA Guidance, 
Navigation, and Control Conference and Exhibit, 
A1AA-2006-6057. 

[6] McNally, D. and D. Thipphavong, September 
2008, Automated separation assurance in the 
presence of uncertainty, ICAS2008-581, 26th 



International Congress of the Aeronautical Sciences, 
Anchorage, Alaska. 

[7] Matthews, Michael P. and Rich DeLaura, 2010, 
Assessment and Interpretation of En Route Weather 
Avoidance Fields from the Convective Weather 
Avoidance Model, 10 th AIAA Conference on 
Aviation Technology, Integration and Operations, 
Fort Worth, Texas. 

[8] Consiglio et al., 2009, Estimation of Separation 
Buffers for Wind-Prediction Error in an Airborne 
Separation Assistance System, Eighth USA/Europe 
Air Traffic Management Research and Development 
Seminar (ATM2009). 

[9] Wing et al., 2010, Comparison of Airborne and 
Ground-Based Function Allocation Concepts for 


NextGen Using Human-In-The-Loop Simulations, 
10 th AIAA Conference on Aviation Technology, 
Integration and Operations, Fort Worth, Texas. 

Acknowledgements 

The authors gratefully acknowledge the 
generous and expert contributions of the many NASA 
and contractor research and staff members who 
supported this experiment, and specifically recognize 
and thank David Wing, Mike Guminsky, Ed Scearce, 
Jim Sturdy, Bob Vivona, Dave Roscoe, David Karr, 
John Bunnell, Chris Wyatt, Clay Hubbs, Troy 
Landers, and Joey Ponthieux. 

30th Digital Avionics Systems Conference 
October 16-20, 2011 



